This document describes a list of coding conventions that are required for code submissions to the project. By default, the coding conventions for most Open Source Projects should follow the existing coding conventions in the code that you are working on. For example, if the bracket is on the same line as the if statement, then you should write all your code to have that convention.
If you commit code that does not follow these conventions and you are caught, you are responsible for also fixing your own code.
Below is a list of coding conventions that are specific to gvSIG, everything else not specificially mentioned here should follow the official Sun Java Coding Conventions
As explained in the Sun Java Coding Conventions:
Code conventions are important to programmers for a number of reasons:
Having coding conventions is nice but having a way to ensure they are applied is even better ... :-)
The gvSIG maven configuration has a checkstyle target which performs coding conventions using the Checkstyle tool.
Please run this target before committing any code.
Also the eclipse configuration needed to format the source code taking into account the code conventions defined in the current document will be available in the org.gvsig.maven.base.build project, from the gvsig-tools OSOR project.
If the project you are working with has a prepare-workspace.xml file which you have used to configure your workspace, you will have those files already downloaded and available into the folder:
WORKSPACE/org.gvsig.maven.base.build/eclipse-configs
Otherwise, you may download all the files through the repository URL:
To import those configurations perform the following:
Headers
Look at the Headers document for more information.
Indentations
4 spaces. NO tabs.
Javadoc
All API interfaces and classes must be fully documented through javadocs comments at interface/class, method and package level.
When you inherit or extend from another interface or class which is already documented, and implement or rewrite one of the parent methods, don't write any javadoc comments, as they are also inherited since java 1.4.
Brackets
All brackets should begin at the end of the line that begins the statement, and end on a new line indented to the beginning of the statement. Example:
AVOID:
public class MyClass
{
public void someMethod()
{
if (...) { // Do something }
}
}
RIGHT:
public class MyClass {
public void someMethod() {
if (...) {
// Do something
}
}
}
Brackets are mandatory even for single line statements:
if (expression) // AVOID!
// some code
if (expression) { // RIGHT
// some code
}
Blank Spaces
Keywords followed by a parenthesis should be separated by a space. Example:
while (true) {
// some code
}
Blank space should appear after commas in argument lists. Binary operators should be separated from their operands by spaces:
a += c + d;
a = (a + b) / (c * d);
while (d++ = s++) {
n++;
}
printSize("size is " + foo + "\n");
Class variables
Class variables should not have any prefix or suffix related to its data type or scope. Example:
String nameString; // AVOID!
String name; // RIGHT
Parameter names
Method parameters should be prefixed by "the" for differentiating them from inner variables, when there is an inner variable with the same name or use. For example:
public void someMethod(String theClassName) {
String className; // inner variable
}
Line length
Avoid lines longer than 80 characters for Code, comments, ...
Versioning
All .java files should have a @version tag like the one below into the class javadoc comment:
@version $Id$
Logging
Do not use System.out to log. Instead, use the SLF4J logging API. For example:
private static final Logger LOG =
LoggerFactory.getLogger(MyClass.class);
public void someMethod() {
LOG.debug("some debug text");
}
For more information on SLF4J usage, you can read the Logging document.
Exception handling
Managing exceptions correctly requires experience. This is not supposed to be a guide on managing exceptions, simply a few best practices.
An example:
public void getTestClass() {
try {
Class responseClass =
Class.forName("some.package.MyClass");
} catch (ClassNotFoundException cnfe) {
String message = "Cannot instantiate test class";
LOG.error(message, ex);
throw new ChainedRuntimeException(message, e);
}
}
Qualified imports
All import statements should containing the full class name of classes to import and should not use the "*" notation: An example:
// AVOID!
import java.util.*;
import java.net.*;
// RIGHT
import java.util.Date;
import java.net.HttpURLConnection;
Use interfaces in the declaration of methods and variables.
By example, if you need a variable x that is a list, declare it as List instead an ArrayList:
// AVOID!
ArrayList x = new ArrayList();
HashMap y = new HashMap();
public HashMap create(ArrayList keys, ArrarList values) {
...
}
// RIGHT
List x = new ArrayList();
Map y = new HashMap();
public Map create(List keys, List values) {
...
}
API packages
Usually, API interfaces and classes will belong to the library's main root package. If you create subpackages, use them to group by functionality, not by type.
How to name packages
All packages must begin with org.gvsig.
For more information on this convention, you can read the How to name packages document.
Attention!
TODO
For more information on this convention, you can read the How to name interfaces and classes document.